A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawing hereto: Copyright (copyright) 1998, Microsoft Corporation, All Rights Reserved.
This invention relates generally to database systems, and more particularly to providing custom actions within a database to perform software installation and semantic validation.
Software installation programs are intended to make it easy for computer users to install and upgrade software applications. Typically these installation programs copy files from an installation disk to desired directories on the user""s computer. In addition, installation programs may update the computer""s registry with desired information. More sophisticated installation programs also insure that any prerequisites to running the applications being installed have been met.
Until recently, installation programs have been procedurally based. That is, the installation program executes a series of steps in one or more procedures designed to copy files, update registry information, and configure the installed application. Each application to be installed typically required an installation script to be developed specifying the steps to be performed.
While procedural based installation programs made installing software applications easier, several problems remained. First, bugs in the installation software resulted in defective installations, resulting in user frustration, and worse, possible system software damage.
In addition, maintenance costs for procedural installation programs can be high. For example, many procedural installation programs are executed as a series of scripts outlining the steps to take. Finding and fixing bugs requires locating which script of a number of scripts is causing the problem. Also, the problem may be spread across a number of related scripts. Furthermore, the same problem may exist in multiple scripts, requiring each and every script to be located and fixed.
A related problem is that relationships between the scripts and procedures in a procedural based installation program may be hard to determine. Making a change to one procedure or script may result in a bug appearing in a different script.
Standardized installation programs were developed to address some of the above problems. Standardized installation programs were intended to solve some of the development and maintenance problems with previous installation programs by providing a set of common user interface modules and standardized methods for copying files and updating registry entries. Typically, the data for the installation is provided in a file, an example of which is the xe2x80x9c.infxe2x80x9d file supported by Microsoft. These files contain various installation parameters and data items.
However, because each software package and each system is different, not all installation actions can be standardized. As a result, standardized installation programs typically must provide what is known in the art as xe2x80x9chooksxe2x80x9d or entry points into the standard installation program for a developer to invoke a custom installation program. While these hooks provide for customization of an installation, the custom installation programs are typically self contained and do not communicate with the standard installation program, and therefore cannot affect the course of the remaining steps of the installation.
In addition, it is difficult to validate the data in the installation data file. The files typically contain a series of keyword and value pairs, with sections of related data delimited by heading indicators. The sections and the text within a section can typically be in an arbitrary order. Generally, in order to validate the data using the above-described format, a custom data file validation program must be developed.
The next step in the evolution of installation programs has been the replacement of procedural installation programs with a database oriented installation program. Software installation can then be data driven, rather than procedure driven. Tables in the database specify files to be copied, registry entries to be entered, and other related installation data. Standard, built-in procedures then operate on this data. This has the advantage that installation maintenance and bug fixes are concentrated in one place, the database. In addition, standard low-level database validation techniques such as referential integrity can be performed on the data in the database.
While the above advantages are significant, several problems remain. First, some level of procedural customization is still required, even in a data driven system. Some database systems support the concept of a stored procedure, which allows a developer to invoke database procedures stored in the database. However, these procedures are generally limited to executing SQL database statements, and cannot interact with other components of the operating system providing file or registry services, nor can they communicate with the installation program to affect the remaining course of the installation.
In addition, while a database engine can typically provide a low-level syntactical validation of data elements and can ensure referential integrity, a database engine cannot provide for semantic validation of the data in the database, i.e. it cannot ensure that the data in the database is valid for a particular application and that the data is internally consistent. For example, a conventional database engine cannot determine that if data defining a dialogue box is present, that all of the buttons in the box have an action associated with them.
A second problem is that a database engine cannot properly validate circular references in the data. An example of a circular reference in the software installation context occurs when a table providing details on a component refers to a table comprising files in the installation package, and the table comprising files refer to the components in which the file is used. Because each table refers to the other, a circular reference is created. Standard database validation techniques cannot be used on such a reference, a custom validation action is required.
An example of a circular reference in the semantic validation context occurs in the data structures defining a dialogue box. A typical dialogue box allows a user to use a tab character to cycle through all the options available in the box. The database reflects this by providing a link from one data structure to the next, with the last linking to the first. Thus a circular reference is created. Again, standard database validation techniques cannot validate the structure, a custom action is required.
Thus what is needed is a system that provides to ability for a developer to provide custom actions within a software installation system. The system must provide for two-way communication between the custom action and a client application. The system should allow for multiple types of custom actions, and it should be easy to combine multiple actions into sequences of actions. In addition, the system should provide for invoking validation procedures that can validate the semantics of the data in the database as they relate to a particular software application installation. The validation procedures and data should be capable of being installed separately from any product related or installation-related data.
The above-identified problems, shortcomings and disadvantages with the prior art, as well as other problems, shortcoming and disadvantages, are solved by the present invention, which will be understood by reading and studying the specification and the drawings. A system of the invention includes a database engine module for maintaining a database. The database contains a custom action table, with columns in the table providing information about the action. Each row in the table represents an individual action. The system also includes an installation engine module operative to read an action value from an action column of the action row and causing an action specified by the action value to be performed by a computer. The actions can be executable programs, dynamically loadable code such as Dynamic Link Library modules, or scripts written in scripting languages such as JavaScript or Visual Basic.
The custom actions can be invoked individually or as part of a sequence of other actions. In addition, the actions can be grouped as part of a transaction and executed when the transaction is committed.
Another aspect of the invention is that data defining the custom actions and sequences of actions to be performed can be maintained in multiple databases. This allows one database to store custom actions used for installing a software product, and another database to be used to store custom actions for semantically validating a database. The validation database can be merged with the installation database when validation is required.
Thus embodiments of the invention provide advantages not found in prior systems. The system allows a data-driven software installation program to be customized by defining custom actions that are invoked as necessary. Developers can make use of the services of a standardized data-driven installation engine, while having the flexibility to customize the installation when required. Moreover, the developer can build upon already existing actions using standard database techniques to edit a sequence table to include both the newly defined and pre-existing actions.
A further advantage is that databases shipped as part of a software package are smaller and more efficient. This is because the package need only provide the custom actions new or unique to the package. The new custom actions can then be xe2x80x9cplugged inxe2x80x9d to a database containing other custom actions. The entire set of custom actions is then available for use, either on a temporary or permanent basis. If the new custom actions are only required temporarily, they can be removed when no longer needed.
The system allows for a variety of different action types, providing a developer flexibility in using a variety of system resources beyond what is provided by a standard database engine. For example, the developer can call executable programs and scripts that can examine and set various system parameters. Furthermore, the actions can be written in an easy to use scripting language. The scripting language provides a more powerful and robust environment to define actions than the standard SQL and stored procedures typically available in a database engine.
The invention includes systems, methods, computers, and computer-readable media of varying scope. Besides the embodiments, advantages and aspects of the invention described here, the invention also includes other embodiments, advantages and aspects, as will become apparent by reading and studying the drawings and the following description.